Secure payment and billing method using mobile phone number or account

ABSTRACT

A system, method and computer program product for processing payments for goods or services, including a payment processor that receives a payment request from a merchant for goods or services and that includes a mobile phone number or mobile phone account of a user, sends a payment authorization request text message to the mobile phone requesting payment authorization, and receives a payment authorization text message from the mobile phone authorizing or not authorizing the payment. If the payment is authorized, the payment processor pays the merchant and charges the mobile phone account for the payment. If the payment is not authorized or if the payment is not received within a predetermined period of time, the payment processor declines to pay the merchant for the goods or services.

CROSS REFERENCE TO RELATED APPLICATIONS

The present invention is a continuation of co-pending, U.S. patentapplication Ser. No. 13/148,043 of Rammal, entitled “SECURE PAYMENT ANDBILLING METHOD USING MOBILE PHONE NUMBER OR ACCOUNT,” filed on Aug. 4,2011, now allowed, which claims the benefit of priority from PCT PatentApplication Serial No. PCT/US10/23863 of Rammal, entitled “SECUREPAYMENT AND BILLING METHOD USING MOBILE PHONE NUMBER OR ACCOUNT,” filedon Feb. 11, 2010, now expired, U.S. Provisional Patent Application Ser.No. 61/152,696 of Rammal, entitled “SECURE PAYMENT AND BILLING METHODUSING MOBILE PHONE NUMBER OR ACCOUNT,” filed on Feb. 14, 2009, nowexpired, the entire contents of all of the disclosures of which arehereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to methods and systems forconducting secure purchase and payment transactions, and moreparticularly to a method, system and computer program product forconducting secure purchase and payment transactions using a mobilephone.

2. Discussion of the Background

Customers in today's world have unprecedented access to retailers andmerchants selling goods and/or services of all types in stores, throughvendors and vending machines, restaurants and the internet. Beyond thetraditional shopping practice of buying goods and services in ones ownneighborhood, town, city, and country, access to foreign goods andservices is made possible through travel and/or the internet.

Once customers select their goods, they have several options to pay theretailer/merchant with. While cash is still “king,” customers have otherpayment options such as using credit cards, debit cards and paymentservice providers that act on behalf of customers as intermediariesbetween financial institutions and retailers to try and protectcustomer's financial and personal information. Other payment optionsalso include, pre-paid credit/debit cards, stored value cards, bankchecks, bank transfers, travelers checks, money order, demand drafts,money transfer using a third independent financial entity, E-mailpayments, and mobile wallet applications that act as intermediaries orinterfaces between a customer's financial institution (typically a bankor a credit card company) and the retailer/merchant. Certain computerbased financial services software programs also provide transactionpayment features.

However, all these payment options have their merits and demerits andvarious complexities. Customers are still weary about giving theircredit card and personal information to pay for purchases on theinternet, even at stores, restaurants and vending machines as fraud andidentity theft cases have occurred and are on the rise. Given the surgein identity theft, one can't blame customers for fearing the worst. Inaddition, use of the other financial transaction instruments may becostly or sheer complex cumbersome.

Accordingly, customers are constantly looking to simplify their life andreduce complexities in any way possible as long as it doesn't jeopardizetheir personal or financial security. Given that security, fraud andidentity theft are major concerns, it is imperative that customers areprotected. Customers are also weary of unreasonable hidden costs thatare additionally charged by credit cards, mobile wallets and otherfinancial instruments that are above and beyond what the retailer isalready charging.

Conventional systems of payment and methods using mobile phones havelimitations, including requiring downloading of complex software, needto use hi-tech mobile phones, need for additional security codes, hiddencosts, and additional charges by the customer's bank or credit cardcompany. In addition, such complex mobile phone payment systems andother payment methods are also limited in their availability and usagefor the world's population at large that purchases goods and services.The estimate for the world's population stands at 6.6 billion in 2008.Less than 30% of the world's population has credit cards. However,almost 70% of the world's population has a mobile phone and an activemobile account and a robust system and method to leverage this markethas yet to be developed.

SUMMARY OF THE INVENTION

Accordingly, there is a need for a method and system that addresses theabove and other problems with convention transaction and payment systemsto leverage the opportunity for a mobile phone user, anywhere in theworld, with the most basic mobile phone device, a mobile number/account,and a mobile phone service provider to be able to pay for goods andservices locally as well as globally using their mobile phonenumber/account. The above and other needs are addressed by the exemplarymethod and system for conducting secure purchase payment transactionsusing a mobile (e.g., a cell phone) phone number (or e.g., a mobilephone account number) which, at the prompt of the retailer, via apayment processor and the customer's mobile phone service provider, isthen approved and authenticated by the customer/user using their uniquepassword or PIN Code, and hence their mobile phone account is debited bythe mobile phone service provider (e.g, who may or may not include anadditional charge) who then pays the payment processor who then pays theretailer.

Accordingly, in exemplary aspect of the present invention there isprovided a novel system, method and computer program product forprocessing payments for goods or services, including a payment processorthat receives a payment request from a merchant for goods or servicesand that includes a mobile phone number or mobile phone account of auser, sends a payment authorization request text message to the mobilephone requesting payment authorization, and receives a paymentauthorization text message from the mobile phone authorizing or notauthorizing the payment. If the payment is authorized, the paymentprocessor pays the merchant and charges the mobile phone account for thepayment. If the payment is not authorized or if the payment is notreceived within a predetermined period of time, the payment processordeclines to pay the merchant for the goods or services.

Still other aspects, features, and advantages of the present inventionare readily apparent from the following detailed description, byillustrating a number of exemplary embodiments and implementations,including the best mode contemplated for carrying out the presentinvention. The present invention is also capable of other and differentembodiments, and its several details can be modified in variousrespects, all without departing from the spirit and scope of the presentinvention. Accordingly, the drawings and descriptions are to be regardedas illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the present invention are illustrated by way ofexample, and not by way of limitation, in the figures of theaccompanying drawings and in which like reference numerals refer tosimilar elements and in which:

FIGS. 1-2 illustrate an exemplary process for customers to purchasegoods and/or services from a retailer;

FIGS. 3-7 illustrate an exemplary flow chart corresponding to theexemplary process of FIGS. 1-2; and

FIGS. 8-11 illustrate the operation of an exemplary system correspondingto the exemplary process and flow chart of FIGS. 1-7.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention includes recognition of and addresses problemsassociated with conventional systems such those described in U.S. Pat.No. 5,991,749 and United States Patent Application Nos. 20050086164;20050222917; 20070063017; and the like. Although such systems andmethods may provide peer to peer deposits and value transfers, mobiledevice identification centric authentication, mobile wallet software,voice activated and device based user prompted payment functions, andmobile banking, etc., to address payment security and convenience to acertain level, such conventional system and methods still may compromisesecurity, leave customers vulnerable to identity theft, and requirecomplex customer billing systems and procedures. Advantageously, theexemplary method and system for conducting secure purchase paymenttransactions using a mobile phone number recognizes and addresses theseand other limitations with such conventional systems and providecustomer control over payment authorization, identity protection, andsecurity through a simple and convenient payment method.

Advantageously, the novel method and system of the exemplary embodimentsaddresses the above and other problems with conventional paymentprocessing systems and methods and allow the 4 billion plus and growingmobile phone users worldwide to pay for goods and services through theirmobile phone service provider, using their mobile phone number and/ormobile phone account number (also referred to as “mobile number” or“mobile phone number”) securely for goods and/or services they purchaselocally and/or globally. The novel system and method enables online andoffline commerce transactions using mobile phone numbers, with customersbeing billed by their mobile phone service provider/operator/carrier(also referred to as “mobile operator”).

The novel system and method, advantageously, provides a simple andsecure payment system based on a novel process that enables a customerto remain in control of the payment authorization process by using theirmobile phone number to pay for purchases of goods and services, forexample, at the point of sale or via the internet, via telephone salespersons or other interactive interfaces, via vending machines, othersuch retail environments and interfaces, and the like, or any othersuitable way that a retailer or merchant may be selling goods and/orservices, locally or globally, and get billed for the transaction bytheir mobile operator who then settles payment on the customer's behalfwith the retailer through a payment processor.

As compared with conventional systems, the novel system and process doesnot require mobile phone users to download any additional software on totheir mobile phone devices, as long as their mobile phones are able toreceive and send Short Message Service (SMS) text messages, and thelike. Nor are users required to register or create any financialrelationship with a retailer or vendor or a transaction paymentprocessing/clearing house (also referred to as “payment processor”). Nordo users need to disclose their password or personal identification(PIN) code, and the like, to a retailer or a payment processor,advantageously enhancing security levels and protection againstfinancial fraud and identity theft. By not requiring customers toestablish a relationship between their financial institutions (e.g.,banks, credit card companies, money managers and others) and/orretailers, and/or payment processors, the novel system and methodprovides a customer with the advantage of always being in control ofauthorizing the transaction payment, which is eventually billed to themthrough their mobile operator.

The exemplary method involves a customer buying goods and/or servicesand opting to pay for the goods and/or services through their mobileoperator by providing the retailer their mobile number (and e.g.,related information where necessary, such as country that the mobilenumber is issued in and the name of the mobile operator that issued themobile number, such as AT&T or T-Mobile or Verizon, etc.). The retailerthen requests the customer's mobile operator's approval, and customerauthentication and authorization to bill the payment charge to thecustomer's mobile number with the amount of the purchase (the customer'smobile operator may or may not add a surcharge in the case of pre-paidand may or may not in the case of post-paid customers) through a paymentprocessor, for example, of a company that offers this novel service toretailers, mobile operators, and customers.

The mobile operator checks the customer's mobile number account balance(or charge protocols that can be set mutually with post-paid and/orpre-paid customers) and if found sufficient to pay for the purchase (andany additional charges that the mobile operator may levy), sends a SMStext message to the customer on their mobile number giving them detailsof the retailer and the total amount payable (which may or may notinclude additional charges of the mobile operator), and requesting aresponse from the customer for approval via text message, replying withtheir unique PIN Code associated with the customer's mobile number andaccount, or a simple “no” as a response to reject the transactionpayment (and which may not be necessary as the transaction will notconsummate without a positive response in any case). In the case thatthe customer may decide not to respond, after a pre-set time lapse, themobile operator will consider the customer's inaction as a “no” andreject the transaction payment.

If, however, the customer wants to approve the transaction payment, thecustomer replies to the mobile operator's text message by simply sendinga text message with their PIN Code for authentication purposes, allowingthe mobile operator to then deduct or bill the amount to the customer'smobile number account. Upon receiving the PIN Code text message andhaving authenticated the customer's PIN Code, the mobile operator debitsthe customer's account balance for the total amount (e.g., including anyadditional mobile operator surcharges). The mobile operator then sendsapproval to the payment processor creating a liability to pay the netamount due as per the terms agreed between the two parties. By contrast,most conventional systems bill the customer's financial institution(e.g., a credit card company, bank, etc).

The payment processor sends the approval to the retailer, creating aliability to pay the retailer the net amount due as per the terms agreedbetween the two parties. The retailer, upon receiving the approval fromthe payment processor, concludes the transaction and sends the customera receipt via text message and/or other means such as email, mail, andthe like. Advantageously, the retailer can include shipping information,promotional messages and/or coupons along with or following the receiptto the customer.

Referring now to the drawings, wherein like reference numerals designateidentical or corresponding parts throughout the several views and moreparticularly to FIGS. 1-2 thereof there is illustrated an exemplarygeneral process flow, according to an exemplary embodiment. In FIG. 1,the process begins with customer 102 who interfaces/interacts 103 with aretailer's 104 store, e-store (e.g., web site), telephone sales persons,interactive voice response (IVR) system, vendor, restaurant, other suchinterface, and the like, and including personal face-to-face,purchase/consumption of goods and/or services. Customer 102selects/purchases or consumes goods and/or services 105 from retailer104 and proceeds to pay for it at check-out 106 where he has severalpayment options to choose from. Customer 102 chooses a mode of payment107. The retailer 104 requests customer's mobile number and relatedbilling data 108 of customer 102. Customer 102 provides data (a) 108relating to his mobile number, mobile operator 112 and may or may notneed to provide the country that the phone number is registered andissued in. Retailer 104 packages the customer 102 data (a) 108 and addshis invoice detail and sends data (b) 109 to a payment processor 110.Payment processor 110 adds their own transaction ID and other relevantinformation, to the retailer's data (b) 109 and sends data (c) 111 tothe customer's 102 mobile operator 112.

In FIG. 2, the mobile operator 112 adds their transaction ID, otherrelevant information, and or any additional charges to the retailer'sinvoice and packages it as data (d) 212 and sends it as a Text message(e.g., a SMS text message, etc.) to the customer's 102 mobile numberrequesting approval or rejection of payment using a means ofauthentication/authorization with their PIN Code, or “no,” or ignoringthe message (with a pre-set time lag) to reject the approval request.Customer 102 by authenticating/authorizing 213 approves the charge usinga PIN Code sent via a reply through text message data (e) 214 to themobile operator 112, confirming the payment approval. Mobile operatorsends an approval/confirmation data (f) 215 package to the paymentprocessor 110 creating a liability to pay as per the terms agreedbetween the two parties. Payment processor 110 sends approvalconfirmation with relevant transaction data (g) 216 to the retailer 104creating a liability to pay as per the terms agreed between the twoparties. Retailer 104 prepares receipt and sends data (h) 217 via textmessage and/or email or other such means, including but not limited to,mail to customer 102 to conclude the transaction. The data may includeshipping and promotional information.

FIGS. 3-7 illustrate an exemplary flow chart corresponding to theexemplary process of FIGS. 1-2. In FIG. 3, the customer 301 selectsgoods and/or services, for example, from a retailer/vendor/merchant atstep 302 at a store, on the internet, vendor, vending machine,restaurant, mobile browser, through a telephone sales person or salesIVR, and/or other such sales avenues/interfaces as the customer may bepresented with by the retailer. Retailer at step 303 presents thecustomer with various payment options, for example, including cash,credit card, debit card, mobile wallet, mobile phone number or account,bank transfer, stored value cards, and others.

In FIG. 4, the retailer presents various payment options at step 401 tothe customer who selects a payment option at step 402 and chooses to paywith the customer's mobile number at step 403. Should the customer notchoose to pay using the mobile number, step 403 ends the process.Customer provides information related to their mobile number for billingat step 404 whereby the information can include, for example, mobilephone number, mobile operator and the country the mobile number andmobile operator are registered in. Retailer adds transaction details atstep 405, for example, including retailer name and ID, store number,invoice number, goods and/or services purchased, amount billed andpayable by customer and sends it to the payment processor to seekpayment approval, authorization and authentication from the customer andthe customer's mobile operator's agreement, and that of the paymentprocessor to pay the retailer on behalf of the customer. Paymentprocessor adds a unique transaction ID code at step 406 related to theinformation received by the retailer (e.g., whose account would alreadyexist in the database of the payment processor) and any otherinformation that may be relevant, and sends it across to the customer'smobile operator (whose account would also already exist in the databaseof the payment processor).

In FIG. 5A, the payment processor sends the transaction data and ID andthe amount payable by the customer to the customer's mobile operator atstep 501 who receives it at step 502 and verifies the customer at step503. If the customer's mobile number is not verified as a customer ofthe mobile operator, then the error is referred to the payment processorand further detailed in FIG. 5B. If the mobile operator confirms thecustomer, it then proceeds to check their balance in the case of, forexample, pre-paid customers, and/or the payment limit protocols as maybe set/mutually agreed with the mobile operator in the case of, forexample, post-paid customers at step 504. If the pre-paid customer'sbalance is insufficient or the post-paid customer has exceeded theirpayment limit protocol, then the low balance or limit exceeded messageis sent to the customer via text message and further detailed in FIG.5C. If the balance and payment limit protocol is sufficient to cover thepayment due to the retailer and an additional charge that may or may notbe levied by the mobile operator, the customer is then sent a textmessage requesting approval for the mobile operator to charge thecustomer's mobile number to pay the retailer for the transaction at step505. The request for approval message includes, for example, informationstating the retailer's name, total owed for purchases, plus the mobileoperator charge (if applicable) and a request for approval by replyingwith the customer's PIN Code (that would've been already registered bythe customer with the mobile operator for accessing voice mail and/orvalue added services and/or specifically created to access thistransaction payment facility) in a text message to the mobile operator.To reject, the customer would need to send “NO” as a response or justignore the message and a pre-set time lapse protocol at the mobileoperator's end would consider no response from the customer as arejection.

FIG. 5B illustrates the steps associated with a customer verificationerror generated by the mobile operator in FIG. 5A step 503. In FIG. 5B,the mobile operator sends the payment processor a “customer verificationerror” indicating that the mobile number (hence the customer) asindicated by the retailer's data doesn't exist with the mobile operatorat step 507. The payment processor sends the mobile operator's messagealong with the transaction ID (and other data that may be applicable) tothe retailer identifying the customer's mobile number error 508.Retailer receives the error and notifies the customer at step 509.Customer receives notification of error at step 510. Customer thendecides whether to correct the error and provide their mobile numberagain or to use another payment option at step 511. In case customerdecides to choose another payment option at step 512, retailer willprovide that and go to process step as indicated in FIG. 4 step 402. Ifthe customer decides to provide the retailer with their mobile phonenumber at step 513, the retailer performs step 403 of FIG. 4.

FIG. 5C illustrates the steps associated with a customer's accountbalance with the mobile operator being insufficient to pay the totalamount of the transaction (including mobile operator charge whereapplicable) or the customer's payment protocol limit has or would exceedwith the amount that is payable for the transaction (including mobileoperator charge where applicable). In FIG. 5C, the mobile operator sendsthe customer a notification regarding this issue at step 514. Customerreceives the notification at step 515 and then decides whether or not toadd money to their mobile phone account or to pay with anothermethod/option at step 516. In case customer decides to choose otheroption at step 517, retailer will provide that at step 402 of FIG. 4. Ifthe customer decides to add money to their mobile phone account balanceor increase their payment limit at step 518, then they would need toinform the retailer at step 519 to re-submit their mobile number paymentinformation as in FIG. 4 step 405.

In FIG. 6A, the step 505 from FIG. 5A is shown, whereby the mobileoperator sends the customer a text message with the transactioninformation, including but not limited to, retailer's name, total amountpayable to retailer, may or may not add mobile operator surcharge, and arequest to approve or reject payment by replying with a text message tothe mobile operator with either their PIN Code to approve the paymentfor the transaction, or reply “no” or simply ignore the message toaffect a time lapse protocol at the mobile operator's end to reject thepayment approval. Should the customer decide to reject the paymentapproval request by either replying “no” or simply ignoring the messageand thus affecting a time lapse rejection protocol at the mobileoperator end at step 602, then the process is further detailed in FIG.6B. If the customer approves the payment by sending their PIN Code in atext message reply to their mobile operator at step 603, then the mobileoperator receives the PIN Code at step 604, verifies it at step 605 andif correct, logs it as acceptance of the customer to be charged thetotal amount to the mobile number balance or bill. If the PIN Code failsthe mobile operator authentication, the process is further detailed inFIG. 6C.

FIG. 6B describes steps of the process in the case where the customerrejects the approval to pay and the mobile operator logs the customer'srejection to pay at step 606 and sends the payment processor anotification of customer's rejection of payment along with thetransaction ID and other relevant information at step 607. In FIG. 6B,the payment processor tags and sends the rejection notification to theretailer at step 608 who receives it at step 609 and informs thecustomer to choose another payment option. Customer uses another paymentoption at step 610, which goes to step 402 in FIG. 4 to choose a paymentoption.

FIG. 6C describes steps of the process in the case where the PIN Codeapproval text message sent by the customer doesn't authenticate with themobile operator's log of the customer's PIN Code authentication and themobile operator then sends the error message to the customer at step611. In FIG. 6C, the customer receives the notification at step 612 andfollows the steps as per the process detailed in FIG. 6A, step 603. Thisloop for PIN Code can be a predetermined amount times before it isunderstood that the customer can't remember their PIN Code and would beautomatically treated as a rejection and the payment processor would beinformed accordingly. For example, the customer can be sent a final textmessage by the mobile operator asking them to contact customer servicefor help.

FIG. 7 describes the continuation of the process step 605 from FIG. 6A,where the mobile operator verifies the customer's PIN Code successfully,and at step 702 sends approval to the payment processor indicating thenet amount that is payable between the two parties as per theiragreement. In FIG. 7, payment processor receives the approvalnotification and adds other transaction approval information and sendsan approval notification to the retailer indicating the net amount thatis payable between the two parties as per their agreement at step 703.The retailer receives the payment processor's approval notification andlogs it as transaction payment approved and cleared by the customer andpayment owed by the payment processor at step 704. The retailer alsosends the customer a receipt via text message and/or email or othermeans such as, but not limited to, mail, indicating they have receivedindication of payment clearance and may include shipping and promotionalinformation and/or a customer service number at step 705, concluding thetransaction payment process.

Advantageously, the novel method allows a customer to pay a retailerthrough their mobile operator via a payment processor. This methodprotects the financial information of the customer and their identitythat is susceptible to theft and exploitation by malicious acts byparties that may or may not be part of the payment process. The presentmethod as described above virtually presents an anti-fraudulent paymentsystem that provides peace of mind and convenience to customers as theyand their mobile operator are the only ones who know the PIN Code toauthorize payments to retailers.

FIGS. 8-11 illustrate the operation of an exemplary system correspondingto the exemplary process and flow chart of FIGS. 1-7. In FIG. 8, thereis illustrated the mobile number payment system 800, according to anexemplary embodiment of the present invention. The system 800, beginswith the customer 801 who interacts with a retailer's interface 803whereby selecting goods and/or services presented by the retailer to thecustomer to select and/or consume 802 through a variety of waysincluding, for example, retailer's Internet website(e-commerce/e-retail, shop/sales front), telephonesales/retail/catalogue shop/team (call center, catalogue sales), mobilephone enabled shop/sales presence using, for example, WirelessApplication Protocol (WAP) technologies, and the like, interfacing with,for example, the internet, physical store front or other suchestablishment in the form of retail store/shop, including, for example,restaurants, vending machines, vendors, third party representatives,point-of-sale including, for example, services such as paymentmechanisms configured for public transport such as taxis, buses,subways/metro/underground and over ground transport/trains/monorails,commercial aircraft/airlines/buses and other transport, toll-booths,ticket vendors/stands/internet sites for public and private events,exhibits and special occasions, and the like.

The customer selects/consumes goods and/or services and proceeds to payfor it at which point, the retailer provides payment options 805 thatthey accept. The payment options include, for example, mobilenumber/account, cash, credit cards, debit cards, payment serviceprovider, mobile wallet, mobile banking, stored value card, banktransfer, third party wire transfer, money order, travelers' checks,loyalty scheme value, and other such methods.

In FIG. 9, the customer selects the mobile phone number/account option805 for mobile number payment 902 to pay the retailer and provides theretailer details 901 of their account. Customer enters details 901include the following information, for example, a mobile account/number,indicates the country that it belongs to and the name of the mobileoperator. The retailer packages the customer's mobile data and theinvoice details for the customer's purchase and electronically sends thedata via electronic transmission 903 to a payment processor's database904 through/over/using electronic data transmission means 903, forexample, including: world wide web, the internet, point of sale, mobilephone with minimum of SMS text messaging capability, WAP enabled wire orwireless device which may or may not be a mobile phone, telephone and/ortelephone call, interactive voice response over phone or mobile phone,telephone input system using interactive selection response (example:press “1” to select Country, Press “2” to select Operator, etc.), onpaper, facsimile transmission, via email, postal mail, encryptedinformation transportability software running on devices capable ofreceiving and sending such encrypted information over, but not limitedto wireless networks, telephone lines, cable networks, internet, mobilenetworks, and the like.

The payment processor's database 904 identifies the retailer and thedata 901, logs the transaction, generates a transaction ID and sends theretailer's payment charge and approval request to the customer's mobileoperator's database 906 through/over/using electronic data transmissionmeans 903, for example, including: world wide web, the internet, pointof sale, mobile phone with minimum of SMS text messaging capability, WAPenabled wire or wireless device which may or may not be a mobile phone,telephone and/or telephone call, interactive voice response over phoneor mobile phone, telephone input system using interactive selectionresponse (example: press “1” to enter customer's mobile number, Press“2” to enter charge, etc.), on paper, facsimile transmission, via email,postal mail, encrypted information transportability software running ondevices capable of receiving and sending such encrypted informationover, but not limited to wireless networks, telephone lines, cablenetworks, internet, mobile networks, and the like.

In FIG. 10, the mobile operator's database 906 receives the data,verifies the customer's mobile phone/account number, checks whether ithas sufficient balance or is within the defined payment protocol as mayhave been agreed between customer and mobile operator, to pay for theretailer's charge (and the mobile operator's surcharge if any). Uponpositive verification, the mobile operator's database 906 sends thecustomer a request via, for example, SMS text message 1001 on theirmobile phone 1002 for approval and authorization with the information1003, for example, including: retailer's name from which the customerhas purchased goods and/or services, retailer's invoice number, totalpayment owed (and the mobile operator's surcharge if any), and a requestfor the customer to reply the SMS text message back with their uniquePIN Code to approve or “NO” or ignore the message to reject the charge.

Customer replies the mobile operator's message by sending their uniquePIN Code to the mobile operator's database 906 via, for example, SMStext message 1004 to approve that mobile operator can charge the totalamount and deduct it from their mobile account balance or bill it totheir monthly mobile account bill. The mobile operator's database 906receives the SMS text message 1004 from the customer, verifies the PINCode and deducts the charge from the customer's account balance or addsit to their monthly mobile phone bill.

In FIG. 11, the mobile phone operator's database 906 generates anapproval message along with the original transaction ID and sends it tothe payment processor's database 904 through/over/using electronic datatransmission means 903, for example, including: world wide web, theinternet, point of sale, mobile phone with minimum of SMS text messagingcapability, WAP enabled wire or wireless device which may or may not bea mobile phone, telephone and/or telephone call, interactive voiceresponse over phone or mobile phone, telephone input system usinginteractive selection response (example: press “1” to select Approval,Press “2” to select Rejection, press “3” to enter transaction ID, etc.),on paper, facsimile transmission, via email, postal mail, encryptedinformation transportability software running on devices capable ofreceiving and sending such encrypted information over, but not limitedto wireless networks, telephone lines, cable networks, internet, mobilenetworks.

The payment processor's database 904 receives the approval from themobile operator's database 906 via electronic data transmission 903 andlogs the approval and information, debits the operator's account withthe amount due by the operator under the agreed terms between the twoparties, creates a liability to pay the retailer in their account as perthe terms agreed between the two parties and sends an approval to theretailer 803 through/over/using electronic data transmission means 903,for example, including: world wide web, the internet, point of sale,mobile phone with minimum of SMS text messaging capability, WAP enabledwire or wireless device which may or may not be a mobile phone,telephone and/or telephone call, interactive voice response over phoneor mobile phone, telephone input system using interactive selectionresponse (example: press “1” to select Approval, Press “2” to selectRejection, press “3” to enter transaction ID, etc.), on paper, facsimiletransmission, via email, postal mail, encrypted informationtransportability software running on devices capable of receiving andsending such encrypted information over, but not limited to wirelessnetworks, telephone lines, cable networks, internet, mobile networks.

The retailer 803 receives the approval from the payment processor 904,logs it in their books and generates a payment receipt which is sent tothe customer 801. The receipt can be sent through/over/using electronicdata transmission means 903, for example, including: world wide web, theinternet, point of sale, mobile phone with minimum of SMS text messagingcapability, WAP enabled wire or wireless device which may or may not bea mobile phone, telephone and/or telephone call, interactive voiceresponse over phone or mobile phone, telephone input system usinginteractive selection response (example: press “1” to select Approval,Press “2” to select Rejection, press “3” to enter transaction ID, etc.),on paper, facsimile transmission, via email, postal mail, encryptedinformation transportability software running on devices capable ofreceiving and sending such encrypted information over, but not limitedto wireless networks, telephone lines, cable networks, internet, mobilenetworks. The customer 801 receives the receipt and other relevantinformation to their purchase, including but not limited to shippinginformation, promotional offers, promotional coupons, promotionalbar-codes, gift certificates, etc.

The above-described devices and subsystems of the exemplary embodimentscan include, for example, any suitable servers, workstations, PCs,laptop computers, PDAs, Internet appliances, handheld devices, cellulartelephones, wireless devices, other devices, and the like, capable ofperforming the processes of the exemplary embodiments. The devices andsubsystems of the exemplary embodiments can communicate with each otherusing any suitable protocol and can be implemented using one or moreprogrammed computer systems or devices.

One or more interface mechanisms can be used with the exemplaryembodiments, including, for example, Internet access, telecommunicationsin any suitable form (e.g., voice, modem, and the like), wirelesscommunications media, and the like. For example, employed communicationsnetworks or links can include one or more wireless communicationsnetworks, cellular communications networks, G3 communications networks,Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs),the Internet, intranets, a combination thereof, and the like.

It is to be understood that the devices and subsystems of the exemplaryembodiments are for exemplary purposes, as many variations of thespecific hardware used to implement the exemplary embodiments arepossible, as will be appreciated by those skilled in the relevantart(s). For example, the functionality of one or more of the devices andsubsystems of the exemplary embodiments can be implemented via one ormore programmed computer systems or devices.

To implement such variations as well as other variations, a singlecomputer system can be programmed to perform the special purposefunctions of one or more of the devices and subsystems of the exemplaryembodiments. On the other hand, two or more programmed computer systemsor devices can be substituted for any one of the devices and subsystemsof the exemplary embodiments. Accordingly, principles and advantages ofdistributed processing, such as redundancy, replication, and the like,also can be implemented, as desired, to increase the robustness andperformance of the devices and subsystems of the exemplary embodiments.

The devices and subsystems of the exemplary embodiments can storeinformation relating to various processes described herein. Thisinformation can be stored in one or more memories, such as a hard disk,optical disk, magneto-optical disk, RAM, and the like, of the devicesand subsystems of the exemplary embodiments. One or more databases ofthe devices and subsystems of the exemplary embodiments can store theinformation used to implement the exemplary embodiments of the presentinventions. The databases can be organized using data structures (e.g.,records, tables, arrays, fields, graphs, trees, lists, and the like)included in one or more memories or storage devices listed herein. Theprocesses described with respect to the exemplary embodiments caninclude appropriate data structures for storing data collected and/orgenerated by the processes of the devices and subsystems of theexemplary embodiments in one or more databases thereof.

All or a portion of the devices and subsystems of the exemplaryembodiments can be conveniently implemented using one or more generalpurpose computer systems, microprocessors, digital signal processors,micro-controllers, and the like, programmed according to the teachingsof the exemplary embodiments of the present inventions, as will beappreciated by those skilled in the computer and software arts.Appropriate software can be readily prepared by programmers of ordinaryskill based on the teachings of the exemplary embodiments, as will beappreciated by those skilled in the software art. Further, the devicesand subsystems of the exemplary embodiments can be implemented on theWorld Wide Web. In addition, the devices and subsystems of the exemplaryembodiments can be implemented by the preparation ofapplication-specific integrated circuits or by interconnecting anappropriate network of conventional component circuits, as will beappreciated by those skilled in the electrical art(s). Thus, theexemplary embodiments are not limited to any specific combination ofhardware circuitry and/or software.

Stored on any one or on a combination of computer readable media, theexemplary embodiments of the present inventions can include software forcontrolling the devices and subsystems of the exemplary embodiments, fordriving the devices and subsystems of the exemplary embodiments, forenabling the devices and subsystems of the exemplary embodiments tointeract with a human user, and the like. Such software can include, butis not limited to, device drivers, firmware, operating systems,development tools, applications software, and the like. Such computerreadable media further can include the computer program product of anembodiment of the present inventions for performing all or a portion (ifprocessing is distributed) of the processing performed in implementingthe inventions. Computer code devices of the exemplary embodiments ofthe present inventions can include any suitable interpretable orexecutable code mechanism, including but not limited to scripts,interpretable programs, dynamic link libraries (DLLs), Java classes andapplets, complete executable programs, Common Object Request BrokerArchitecture (CORBA) objects, and the like. Moreover, parts of theprocessing of the exemplary embodiments of the present inventions can bedistributed for better performance, reliability, cost, and the like.

As stated above, the devices and subsystems of the exemplary embodimentscan include computer readable medium or memories for holdinginstructions programmed according to the teachings of the presentinventions and for holding data structures, tables, records, and/orother data described herein. Computer readable medium can include anysuitable medium that participates in providing instructions to aprocessor for execution. Such a medium can take many forms, includingbut not limited to, non-volatile media, volatile media, transmissionmedia, and the like. Non-volatile media can include, for example,optical or magnetic disks, magneto-optical disks, and the like. Volatilemedia can include dynamic memories, and the like. Transmission media caninclude coaxial cables, copper wire, fiber optics, and the like.Transmission media also can take the form of acoustic, optical,electromagnetic waves, and the like, such as those generated duringradio frequency (RF) communications, infrared (IR) data communications,and the like. Common forms of computer-readable media can include, forexample, a floppy disk, a flexible disk, hard disk, magnetic tape, anyother suitable magnetic medium, a CD-ROM, CDRW, DVD, any other suitableoptical medium, punch cards, paper tape, optical mark sheets, any othersuitable physical medium with patterns of holes or other opticallyrecognizable indicia, a RAM, a PROM, an EPROM, a FLASH-EPROM, any othersuitable memory chip or cartridge, a carrier wave or any other suitablemedium from which a computer can read.

While the present inventions have been described in connection with anumber of exemplary embodiments, and implementations, the presentinventions are not so limited, but rather cover various modifications,and equivalent arrangements, which fall within the purview of theappended claims.

What is claimed is:
 1. A computer implemented system for processingpayments for goods or services, the system comprising: a paymentprocessor configured to receive a payment request for goods or servicesfrom a merchant, wherein the payment request includes a mobile phonenumber associated with a mobile phone account of a user; a mobileoperator servicing the mobile phone account of the user; and a mobilephone of the user connected to a mobile network of the mobile operator;the payment processor based on the payment request is configured to senda payment authorization request to the mobile operator servicing themobile phone account of the user; the mobile operator based on thepayment authorization request is configured to send over the mobilenetwork of the mobile operator a payment authorization request textmessage to the mobile phone of the user requesting authorization forpayment of the payment request; the mobile phone of the user based onpayment authorization request text message is configured to send overthe mobile network of the mobile operator a payment authorization textmessage including a personal identification number of the userassociated with the mobile phone number of the user to the mobile phoneoperator for authorization of payment of the payment request; the mobileoperator is configured to receive the payment authorization text messageincluding the personal identification number of the user over the mobilenetwork of the mobile operator for verification; the payment processoris configured to receive a payment authorization from the mobile phoneoperator based on the payment authorization text message for authorizingor not authorizing the payment of the payment request; if the paymentauthorization from the mobile phone operator authorizes the payment ofthe payment request, the payment processor is configured to pay themerchant for the goods or services from an account of the mobile phoneoperator, wherein the mobile phone operator charges the mobile phoneaccount of the user for the payment; and if the payment authorizationfrom the mobile phone operator does not authorize the payment of thepayment request or if the payment authorization text message is notreceived by the mobile operator over the mobile network of the mobileoperator within a predetermined period of time, the payment processor isconfigured to decline to pay the merchant for the goods or services, andwherein no financial information of the user nor the personalidentification number of the user are sent to the payment processor. 2.The system of claim 1, wherein the mobile operator is configured tocheck an account balance and/or charge protocols of the mobile phoneaccount for payment for the goods or services and additional chargeslevied by the mobile operator.
 3. The system of claim 1, wherein thepayment authorization request text message includes details of themerchant and a total amount payable which can include additional chargesby the mobile operator.
 4. The system of claim 1, wherein the merchantis configured to send a message to the user including shippinginformation, promotional messages and/or coupons along with or followinga receipt to the user.
 5. A computer implemented method for processingpayments for goods or services, the method comprising: providing apayment processor; providing a mobile operator for servicing a mobilephone account of a user; providing a mobile phone of the user connectedto a mobile network of the mobile operator; receiving by the paymentprocessor a payment request for goods or services from a merchant,wherein the payment request includes the mobile phone number associatedwith the mobile phone account of the user; sending by the paymentprocessor based on the payment request a payment authorization requestto the mobile operator servicing the mobile phone account of the user;sending by the mobile operator based on the payment authorizationrequest a payment authorization request text message over the mobilenetwork of the mobile operator to the mobile phone of the userrequesting authorization for payment of the payment request; sending bythe mobile phone of the user based on the payment authorization requesttext message a payment authorization text message over the mobilenetwork of the mobile operator including a personal identificationnumber of the user associated with the mobile phone number of the userto the mobile phone operator for authorization of payment of the paymentrequest; receiving by the mobile operator the payment authorization textmessage including the personal identification number of the user overthe mobile network of the mobile operator for verification; receiving bythe payment processor a payment authorization from the mobile phoneoperator based on the payment authorization text message for authorizingor not authorizing the payment of the payment request; if the paymentauthorization from the mobile phone operator authorizes the payment ofthe payment request, the payment processor is configured to pay themerchant for the goods or services from an account of the mobile phoneoperator, wherein the mobile phone operator charges the mobile phoneaccount of the user for the payment; and if the payment authorizationfrom the mobile phone operator does not authorize the payment of thepayment request or if the payment authorization text message is notreceived by the mobile operator over the mobile network of the mobileoperator within a predetermined period of time, the payment processor isconfigured to decline to pay the merchant for the goods or services, andwherein no financial information of the user nor the personalidentification number of the user are sent to the payment processor. 6.The method of claim 5, wherein the mobile operator is configured tocheck an account balance and/or charge protocols of the mobile phoneaccount for payment for the goods or services and additional chargeslevied by the mobile operator.
 7. The method of claim 5, wherein thepayment authorization request text message includes details of themerchant and a total amount payable which can include additional chargesby the mobile operator.
 8. The method of claim 5, wherein the merchantis configured to send a message to the user including shippinginformation, promotional messages and/or coupons along with or followinga receipt to the user.
 9. A computer program product for processingpayments for goods or services and including one or more computerreadable instructions embedded on a tangible, non-transitory computerreadable medium and configured to cause one or more computer processorsto perform the steps of: providing a payment processor; providing amobile operator for servicing a mobile phone account of a user;providing a mobile phone of the user connected to a mobile network ofthe mobile operator; receiving by the payment processor a paymentrequest for goods or services from a merchant, wherein the paymentrequest includes the mobile phone number associated with the mobilephone account of the user; sending by the payment processor based on thepayment request a payment authorization request to the mobile operatorservicing the mobile phone account of the user; sending by the mobileoperator based on the payment authorization request a paymentauthorization request text message over the mobile network of the mobileoperator to the mobile phone of the user requesting authorization forpayment of the payment request; sending by the mobile phone of the userbased on the payment authorization request text message a paymentauthorization text message over the mobile network of the mobileoperator including a personal identification number of the userassociated with the mobile phone number of the user to the mobile phoneoperator for authorization of payment of the payment request; receivingby the mobile operator the payment authorization text message includingthe personal identification number of the user over the mobile networkof the mobile operator for verification; receiving by the paymentprocessor a payment authorization from the mobile phone operator basedon the payment authorization text message for authorizing or notauthorizing the payment of the payment request; if the paymentauthorization from the mobile phone operator authorizes the payment ofthe payment request, the payment processor is configured to pay themerchant for the goods or services from an account of the mobile phoneoperator, wherein the mobile phone operator charges the mobile phoneaccount of the user for the payment; and if the payment authorizationfrom the mobile phone operator does not authorize the payment of thepayment request or if the payment authorization text message is notreceived by the mobile operator over the mobile network of the mobileoperator within a predetermined period of time, the payment processor isconfigured to decline to pay the merchant for the goods or services, andwherein no financial information of the user nor the personalidentification number of the user are sent to the payment processor. 10.The computer program product of claim 9, wherein the mobile operator isconfigured to check an account balance and/or charge protocols of themobile phone account for payment for the goods or services andadditional charges levied by the mobile operator.
 11. The computerprogram product of claim 9, wherein the payment authorization requesttext message includes details of the merchant and a total amount payablewhich can include additional charges by the mobile operator.
 12. Thecomputer program product of claim 9, wherein the merchant is configuredto send a message to the user including shipping information,promotional messages and/or coupons along with or following a receipt tothe user.